I added a few inline comments in your code.
Additionally, please consider:

• I didn't test it, but I am reasonably confident, that the 400 response contains the information why the request failed (missing required fields). Why can't we use this information for our output? Adding our own business logic for identifying why a request failed should be avoided as long as the information returned by the API is not good enough. As I don't know how the response looks like (without looking it up), please state your case why you deem necessary to add this logic to the module.
• I have an improvement for the error handling staged on my local machine to improve it a bit. take a look if your code could benefit from it (I didn't check):

        $allErrors = ($responseObject.errorMessages + $responseObject.message + $responseObject.errors)

                if ($allErrors.Count -eq 0) {
                    throw "Unable to handle error"
                }

                foreach ($_error in $allErrors) {
                    if ($_error.Count -gt 0) {
                        $writeErrorSplat = @{
                            Exception    = $exception
                            ErrorId      = $errorId
                            Category     = $errorCategory
                            Message      = Out-String -InputObject $_error
                            TargetObject = $targetObject
                            Cmdlet       = $Cmdlet
                        }
                        WriteError @writeErrorSplat
                    }
                }

• You must still update the existing tests to pass with these changes
• You should add new tests (with a mocked 400 response) showing how these errors are handled